Ironic Standalone Operator #461
Conversation
|
Skipping CI for Draft Pull Request. |
metal3-io-bot
added
the
do-not-merge/work-in-progress
metal3-io-bot
added
the
size/L
dtantsur
force-pushed
the
ironic-standalone-operator
branch
4 times, most recently
from
27ec8ca
to
04f201c
Compare
metal3-io-bot
removed
the
do-not-merge/work-in-progress
dtantsur
force-pushed
the
ironic-standalone-operator
branch
2 times, most recently
from
23135d5
to
7be12d1
Compare
| - `dhcp` - another nested structure with DHCP parameters (see below) | ||
| - `externalIP` - IP through which nodes deployed over virtual media access | ||
| Ironic and HTTPD | ||
| - `interface`, `ipAddress`, `macAddresses` - various ways to specify the |
There was a problem hiding this comment.
Similarly, how does provisioningInterface, provisioningIPAddress and provisioningMACAddress sound?
There was a problem hiding this comment.
There is a potential for confusion here. We call "provisioning network" a dedicated network for the PXE and other provisioning traffic. Ironic can work without it, and the variables work regardless of whether you have a "provisioning network".
Maybe I'm overthinking it? Would like more opinions here as well.
There was a problem hiding this comment.
If we do decide to change this, I'd rather rename the whole "networking" sub-field into something like "provisioningNetwork" to avoid duplicate prefixes.
There was a problem hiding this comment.
But the rest of the sub-fields seem unrelated to the provisioning network (like dhcp and external ip)?
How would the interface, ipAddress and macAddresses fields work if there is no provisioning interface?
(I am not too familiar with ironic's networking, so just trying to understand the expected behaviour)
There was a problem hiding this comment.
DHCP is very-very much related to the provisioning network: it's DHCP on the provisioning network. ExternalIP is not directly related indeed, maybe we'd need to move it out then.
How would the interface, ipAddress and macAddresses fields work if there is no provisioning interface?
There must be a provisioning interface, but it can be on some existing network rather than an isolated provisioning network. Confusing, I know. This is why I'm pondering our usage of "provisioning" here.
There was a problem hiding this comment.
I would also say to not use "provisioning", on Bare Metal Life Cycle management level the name "Provisioning Network" makes sense but if we just talk about an ironic instance not that much. Everything Ironic does with the machine goes through the provisioning network, ofc he BMC might have it's own separate network but ipxe, dhcp, bootp, http image server, IPA - Ironic communication they all happen in the "provisioning" network but from Ironic perspective it is simply "the Network".
| avoid running it 3+ times in parallel. Maybe it will take a form of a *Job*. | ||
| - BMO will need to be updated to handle more cases of unexpected provision | ||
| state. E.g. what needs to be done when the BMH is *inspecting* but the node | ||
| is found in a completely wrong state like `active` or `clean wait`. |
There was a problem hiding this comment.
There is an additional complexity to consider if we're going to support mariadb combined with persistent volumes, when the mariadb version changes you either have to ensure clean shutdown of the container or enable some kind of backup/restore workflow due to the mariadb checks around versioning for the redo log - see here for example.
This can likely be resolved with with pod lifecycle hooks, or perhaps some kind of job pre/post upgrade but it's additional complexity which I don't think we currently consider in the community deployment examples.
There was a problem hiding this comment.
Very good point, thank you!
|
/hold |
metal3-io-bot
added
the
do-not-merge/hold
| its private key certificate and sign the certificate with this CA. The CA will | ||
| be trusted **only** for the RPC purpose, removing the possibility of abuse. | ||
| To reduce the number of code paths, this process will happen unconditionally, | ||
| even when TLS for Ironic itself is not enabled. |
There was a problem hiding this comment.
Just for my understanding what prevents us from enabling TLS unconditionally for ironic itself?
There was a problem hiding this comment.
Well, nothing really. We'd need to decide if we want to use a CertificateSigningRequest (and require a manual approval) or just generate a self-signed certificate. Opinions?
There was a problem hiding this comment.
I guess the end goal would be to have an integration with cert-manager as in most K8s environments cert-manager is handling the certificates.
There was a problem hiding this comment.
My only worry about the manual step (approving the cert request). Is it also considered standard?
I mean, in the situation when the admin has not provided any certificate via the secret.
|
I can approve it already and hold can be taken back when the reviews are addressed |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kashifest, Rozzii The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
metal3-io-bot
added
the
approved
This design proposal discusses ironic-standalone-operator: provides a motivation for its creation, describes its goals and outlines the current design and features, as well as the plans for the nearest future. Signed-off-by: Dmitry Tantsur <dtantsur@protonmail.com>
dtantsur
force-pushed
the
ironic-standalone-operator
branch
from
7be12d1
to
eb4b040
Compare
|
/lgtm |
|
LGTM |
|
@kashifest do you feel like your comments have been (at least mostly) addressed? The TLS one is probably the only outstanding (and we can discuss it later if you wish). |
I am fine with this as is. We can continue the TLS discussion as you suggested. |
metal3-io-bot
removed
the
do-not-merge/hold
This design proposal discusses ironic-standalone-operator: provides a
motivation for its creation, describes its goals and outlines the
current design and features, as well as the plans for the nearest
future.
Signed-off-by: Dmitry Tantsur dtantsur@protonmail.com